The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to implementations of the claimed inventions.
Both developers and end users are dealing with large numbers of clients and huge data volumes, popularly referred to as “Big Data” in today's world. Web applications that serve and manage millions of Internet users, such as Facebook™ Instagram™, Twitter™, banking websites, or even online retail shops, such as Amazon.com™ or eBay™ are faced with the challenge of delivering information as fast as possible so that the end users can be provided with a real-time experience.
Businesses need the ability to query and to view query results in real time, large data sets being analyzed, in order to make informed business decisions. An enterprise system that provides business analytics live, for large volumes of data, performs visual data analysis and live data rendering, with flexible display options for analyzing the data and conveying analysis results. Workflow handling for queries is a significant consideration when configuring server node allocation—to optimize for speed and minimize the expense of providing live business analytics.
Existing worker node clusters for an example enterprise system operate as described next. Requests enter the system via a load balancer and get routed to one of a pool of several data structure server nodes. In one implementation, the data structure servers may be Redis nodes. Requests for a given org are hashed to a specific queue number and placed on that queue. Each worker node is assigned a fixed set of queues to monitor. For example, worker one on rack one might be assigned queues 1, 5, 7 and 9. Thus, worker one will service any requests for org IDs that get hashed to one of those queue numbers. To meet the need for assured reliability, at any time of any day, at least three backend servers are configured to monitor the Redis node assigned to process the generated queue. One of the backend servers picks up the work, processes it, and provides results. To ensure availability and maximize throughput, all workers listen to their assigned queues on all Redis nodes.
A salient issue for node configuration is how to spread queue assignments among the nodes available in the backend system. Existing systems are configured by manually running a configuration tool that extracts, from a database that contains a reliable list of information about the hardware, host server systems and their locations—for example, what server is where, on which racks. This configuration data gets extracted from the database, to produce a static set of configuration files, per data center. The configuration files of attribute-value pairs explicitly describe which server is going to handle which queue. In one implementation, the attribute-value pairs can be expressed in JSON, and the JSON results are usable as input to a revision control system, such as PREFORCE. After going through a coordinated release process, including obtaining the necessary signoffs, a series of server restarts can be carefully orchestrated to make changes to the configuration of the backend server nodes. The generated configurations are written in stone until new configuration files are deployed, which requires a repeat of the process just described.
The existing configuration approach, described above, for spreading queue assignments for big data among the nodes in the backend, is limited. Any configuration change, including adding additional server capacity, removing server capacity from the cluster, or reallocation of queues to better service hotspots in the system, requires a full release pipeline.
If any server in the system goes down for any reason, then the orgs that would have hashed to those queues go into degraded mode. The only available fix is for a human to take action and fix the node. Therefore, nodes operate very much as pets, instead of as cattle. If the system loses multiple nodes with queue overlaps, the service may become entirely unavailable for a set of orgs even if plenty of usable capacity is available in the cluster of servers. The requirement for a release cycle to implement configuration changes results in a lack of runtime adaptability, so that every single server gets treated like a precious pet, instead of the preferable perspective of having “cattle”. That is, if a server goes down, ideally a different server would be substituted without a need to nurse the “pet” back to health before proceeding.
For the system described above, because node allocation is a slow and manual process, it is impossible to maximize hardware utilization for the end user's benefit. A large org could be experiencing a very high load with three servers running at maximum capacity, while another fifty servers are doing very little. Temporarily shifting resources around to better balance the load could greatly improve the average end user experience, but the existing configuration system for servers is inflexible at runtime. There is no ability to employ underutilized hardware to adapt to performance hotspots.
Therefore, an opportunity arises for dynamic node allocation for a server system that can automatically heal on failure—a system that minimizes the need for static configuration and is capable of dynamically adjusting server resources to match load, and minimize end user wait times. The disclosed technology relates to dynamically allocating nodes to increase capacity for a platform that accepts data queries and completes ultra-fast, ad-hoc data exploration and faceted navigation on integrated, heterogeneous data sets. The analytic data structures, also referred to as “edgemarts,” are compressed data forms produced from transactional databases, which represent specific form functions of transactional database objects. Sometimes analytic data structures are produced by merging data from multiple database systems or platforms. For instance, prospect and opportunity closing data may come from one enterprise system and order fulfillment data can come from a software-as-a-system. An analytic data structure may combine sales and fulfillment data for particular opportunities, merging data from systems that run on different database platforms, in separate applications from different vendors, applying divergent security models. Dozens of analysts may work on subsets of an overall analytic data structure, both for periodic and ad hoc investigations.